feat(diag): show applied and pending firewall rules - #53

Three sources, because they answer three different questions and are not
interchangeable.

What dezhban recorded installing. internal/applied writes the exact ruleset text
handed to the backend, timestamped, beside state.json at 0644 like the state file
— so the unprivileged menubar app can read it. Recorded by wrapping the runner's
Backend rather than by calling Save at each Apply: the run loop applies from
nineteen places, and a record only as complete as the last person to remember it
is worse than none. The wrapper adds no goroutine and no writer, so the
single-writer invariant is untouched, and it records only after a successful
Apply — a failed one leaves the previous ruleset live, and describing rules that
were never installed is the one thing a reader of this file must be able to rely
on not happening. Unblock and Cleanup clear it, so a stale ruleset can never be
read as the live posture.

What the kernel holds. FirewallBackend gains InstalledRules, implemented for pf,
nft and WFP, each scoped to dezhban's own anchor/table/group so it can never
become a way to dump unrelated firewall state. It is a read: it does not go
through Apply and does not touch the single-writer rule. It needs root, which is
why nothing calls it on a tick. pf and nft additionally flag the loaded-but-not-
evaluated cases their IsBlocked already checks for.

What each posture would apply, which print-rules already rendered purely.

A record with no kernel rules is reported and never repaired — the run loop's
verify tick already owns that, and a second repairer would be a second writer.
Neither surface diffs the two texts: the kernel renders its own normalised form
of what was loaded, so a byte comparison would report drift on every healthy
host.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Found reading the diff before review, not by the reviewer.

print-rules now carries two kinds of flag: one describing a ruleset to
RENDER (--mode) and two selecting a live ruleset to REPORT (--applied,
--installed). Only the --applied/--installed pair was refused. The other
two combinations were accepted and half-discarded:

  print-rules --applied --mode fullblock   # --mode ignored, exit 0
  print-rules --json                       # --json ignored, prints text

Both are the shape this project calls its worst bug — a flag accepted and
then quietly dropped — and the second is the more misleading, since a
caller parsing that output gets firewall syntax where it asked for JSON.
Each is now refused with exit 2 naming the flag to drop, matching the
existing --applied/--installed refusal.

The check is on what the user TYPED, via fs.Visit, not on flag values:
--mode defaults to "guard", so testing its value would reject every plain
--applied run. TestPrintRulesAppliedIsFineWithoutMode pins that, and
TestPrintRulesRefusesFlagsItCannotHonour covers all four refusals — the
two new cases return 0 and 1 on the unfixed code.

Also: CLAUDE.md said the privileged set was "exactly" a list that did not
include this, and listed print-rules among the commands needing no root.
`--installed` reads the kernel back and does need it. Corrected using the
same "X but not X --sub" idiom the paragraph already uses for `setup` and
`vpn list`, and the refusals are documented in cli.md.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Round 2. The headline finding is the loop's own: round 1 taught the
no-rules branch to print the readback text, because on Windows the
blocking lives in each profile's DefaultOutboundAction rather than in the
rule group — and left the DRIFT branch, eight lines above, still throwing
it away. That is the branch taken whenever a record exists, which is
exactly when someone is asking. A host whose group was removed while its
profile default is still Block is fully cut, and was told "the kernel
holds no dezhban rules" with the profile table that proves egress is cut
discarded. Both branches print it now.

From the branch itself:

- pf checked two of the three things IsBlocked checks. An anchor that is
  loaded and referenced while pf is switched off entirely (`pfctl -d`)
  filters nothing, and rendered as a clean readback with no warning. The
  status probe is now there, in the same shape as the anchor-reference
  verdict, and says so.
- The whole Firewall-rules section sat inside the pane's
  `doctorReport != nil || vpnInventory != nil` gate, so the applied record
  and the "Read from the kernel…" button were invisible on a host where
  `doctor --json` cannot run — the state someone is most likely
  diagnosing — and on every first open until the async doctor returned.
  None of the three rows needs doctor. This is the same bug the comment
  right above that gate describes for the VPN inventory, one section over.
- The applied row put the posture in its title and the time only in its
  caption, so a pane held open across GUARD → FULL BLOCK kept reading
  "Applied by dezhban — Guard". The time is now in the title, where the
  claim is made. That read is unprivileged and cheap, which is why it gets
  a timestamp rather than the clearing the kernel row got.
- `--config` was refused but not documented; the help line named
  `--applied` but not `--installed`; and all three completion scripts
  offered neither.

The wiring, not just the helpers, is now tested. Both fixes this loop made
could be deleted with the whole suite still green:
TestEveryDirectFirewallPathKeepsTheRecordHonest walks main.go's AST and
fails when cmdBlock stops recording or cmdPanic/cmdUnblock stop clearing
(an AST guard because all three need root and a real firewall — same
technique, and same reason, as TestNoTestInPackageMainIsParallel), and
TestRunWiresTheRecordingBackend drives Run end to end and fails with
"recorded nothing — the backend was never wrapped" when the decorator is
unwired. Both were confirmed against the unfixed code.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>